前言

這篇是「GraphQL 入門」這個小系列的最後一篇，要來提到 GraphQL 一個非常重要的功能 - Fragment。它可以讓各模組自己定義各自的資料需求，並拼裝合成一個 Query 統一發送到伺服器，是以 GraphQL 為主的前端架構的關鍵。

使用 Fragment

還記得前幾篇所做過的 Query 嗎？

{
  users {
    id
    name
  }
}

其實還可以把欄位定義在 fragment，然後再放進 Query 中：

{
  users {
    ...userInfo
  }
}

fragment userInfo on User {
  id
  name
}

如下圖，會得到一模一樣的回傳值：

不過用 Fragment 到底有什麼好處呢？

第一，可以直接在對應的 Type 上重複查詢這組屬性：

{
  users {
    ...userInfo
    posts {
      id
      title
      author {
        ...userInfo
      }
    }
  }
}

fragment userInfo on User {
  id
  name
}

除了能避免重複寫一樣的屬性，以下要提到的另一個用法才是關鍵重點：拼裝 Query。

拼裝 Query

在我們以往的開發經驗中可以得知，UI Component 的模組化跟 API 呼叫通常是彼此獨立的。雖然只有個別的 UI Component 知道自己需要什麼樣的資料來顯示畫面，但如果讓每個 Component 自行呼叫 API，不只是會發出很多的網路請求拖累效能，還會有很多資料重疊的部分被浪費掉。

假設 Component1、Component2、Component3 都有各自需要的資料，有可能重複有可能不重複。經過 Fragment 的拼裝後，不但能一次拿回來，而且資料欄位會剛好不多不少，是三個 Component 的資料聯集：

{
  users {
    ...userInfoRequiredByComponent1
    ...userInfoRequiredByComponent2
    ...userInfoRequiredByComponent3
  }
}

fragment userInfoRequiredByComponent1 on User {
  id
}

fragment userInfoRequiredByComponent2 on User {
  name
}

fragment userInfoRequiredByComponent3 on User {
  id
  name
}

上圖就如同我們說的一般，用一次的網路往返拿回足夠的資料。這就是包括 Relay 在內的許多 GraphQL 相關前端框架的核心概念。

結語

從這五篇的 GraphQL 文章應該已經可以大概知道它的核心語法與概念，更多的概念例如：Interface、Union、Alias、Directive 等等，想也不必在這邊提及，有興趣的話自然能找到更多的資源，而這系列畢竟是開發 App 的主題，讓我們從下一篇迅速回到正題吧。